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ABSTRACT 



Apparatus and method for minimizing a retransmission of 
signals and messages when an errored message is received 
during an xDSL negotiation procedure of a communication 
session. A receiving section monitors received data related 
to a Frame Check Sequence of an xDSL negotiation proce- 
dure. When the receiving section determines that an errored 
message is received, a retransmission request device trans- 
mits a retransmission request message. The retransmission 
request message indicates which correct message was lastly 
received. However, if a predetermined number of errored 
messages occur, the communication session is terminated. 

30 Claims, 7 Drawing Sheets 
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RETRANSMISSION PROCEDURE AND HSTU-R— handshaking portion of the xDSL remote ter- 

APPARATUS FOR HANDSHAKING minal unit (xTU-R). 

PROTOCOL ITU-T — International Telecommunication Union — 

Telecommunication Standardization Sector; 

The present application claims priority under 35 U.S.C. 5 NAK _ Negative Acknowledge Message; 

§ 119 of U.S. Provisional Application Nos. 60/135,308, filed d/ytc pi nMT, i. c ■ dcA_d c 

on May 21, 1999, and 60/136,230, filed on May 26, 1999, Telephone Service PSD-Power Spec 

the disclosures of which are expressly incorporated by ra 051 ^ 

reference herein in their entirety. PSTN— Public Switched Telephone Network; 

10 RADSL— Rate Adaptive DSL; 

BACKGROUND OF THE INVENTION RTX-Request Retransmit; 

Definitions VDSL — Very high speed Digital Subscriber Line; 

The following definitions are employed throughout the '"J^DSLV ^ ^ SubSCriber 

following discussion: 15 ^ 

* c c • ■ , j xTU-C — central terminal unit of an xDSL: and 

carrier set — a set of one or more frequencies associated ' 

with a PSD mask of a particular xDSL Recommenda- xTU-R— remote terminal unit of an xDSL. 

ti orr 1. Field of the Invention 

downslreanwlirection of transmission from the xTU-C The * tesen } inventio ? 18 f ected t0 , a u hi 8 h «£«? c ° m - 

to the xTU-R* 20 mumcatlons device, such as, for example, but not limited to, 

_ \ . , , ^« . , a modem, a cable modem, an xDSL modem, a satellite 

Galf-an octet having the value 81 tf ; i.e., the ones communication system, a point-to-point wired, or a wireless 

complement of an HDLC flag; communication system, that includes a handshaking or 

initiating signal — signal which initiates a startup proce- initializing protocol, and in particular, to an apparatus and 

dure; 25 method that provides error free communication by detecting 

initiating station — DTE, DCE and other associated termi- errors and requesting the retransmission of errored commu- 
nal equipment which initiates a startup procedure; nication messages. 

message— framed information conveyed via modulated 2 - Discussion of Background and Other Information 

transmission; Recently, new communication methods are being pro- 

metallic local loV^mmunication channel 5, the metal- 30 p0Sed and i° r devel °f d to data ° Q « *«*ed 

lie wires that form the local loop to the customer We pair * at ^ frequency spectrum above a traditional 

premise* V0ice n ( e *£'' z Danci width). For example, various 

.... "flavors" (variations) of digital subscriber line (DSL) 

responding signal^ignal sent in response to an initiating modems haye been/afe being developed> such as> but not 

Slgna1 ' 35 limited to, for example, DSL, ADSL, VDSL, HDSL, 

responding station— station that responds to initiation of SHDSL and SDSL (the collection of which is generally 

a communication transaction from the remote station; referred to as xDSL). Each particular xDSL technology 

session — active communications connection, measured requires a robust start-up or initialization technique. 

from beginning to end, between computers or applica- The ITU-T has published several recommended proce- 

tions over a network; 40 dures for initiating a data communication, the following 

signal — information conveyed via tone based transmis- subject matter of which is expressly incorporated herein by 

sion; reference in their entireties: 

signaling family— group of carrier sets which are integral l ) Recommendation V.8, entitled "Procedures For Start- 
multiples of a given carrier spacing frequency; m S Sessions Of Data Transmission Over The General 

splitter— combination of a high pass filter and a low pass 45 Switched Telephone Network", published in September, 

filter designed to split a metallic local loop into two 19 ??L < . 

bands of operation- 2 ) Recommendation V.8 bis, entitled "Procedures For The 
transaction-sequence of messages, ending with either a | dent ^ ati ° n Selection Of Common Modes Of Opera- 
positive acknowledgment [ACK(l)f a negative m ^ ° ata Circuit-Termmatrng Equipment (DCEs) 
acknowledgment (NAK), or a time-out 50 And Between Data Ternmal Equmments (pTEs) Over The 
. , \ General Switched Telephone Network , published in 
terminal-station; and August> 1996; md 

upstream: The direction of transmission from the xTU-R 3) Recommendation G.994.1, entitled "Handshake Pro- 

to the xTU-C. cedures For Digital Subscriber Line (DSL) Transceivers", 

Abbreviations 55 P ubus hed * n June ^99. 11 ^ noteci tnat tm s document is the 

final version of Temporary Document MA-006, that was 

The following abbreviations are used throughout the published in March, 1999. 

following discussion: Documents (1) and (2), above, pertain to procedures for 

ACK — Acknowledge Message; initiating a data communication over voice band channels. 

ADSL — Asymmetric Digital Subscriber Line; 60 Document (3), above, pertains to initiating a data commu- 

CDSL-Consumer Digital Subscriber Line; nic f a T tioa over xDSI ; channels. 

DSI^Digital Subscriber Line; Unfortunately if a data reception error occurs in a 

„ QV & . ' message, even if the error is only a single bit m length, the 

bbK— frequency Shift Keying; data communication devices must completely restart, from 

™SL— High bU ratC Dl S ltal Subscriber Line ; 65 the beginning, a handshake (initialization) procedure. Since 

HSTU-C — handshaking portion of the xDSL central ter- initialization procedures often involve a plurality of mes- 

minal unit (xTU-C); sages or transactions, and thus, restarting a transmission 
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from the beginning results in a significant loss of informa- According to another feature of the invention, the cona- 
tion and time. Thus, there is a need for an apparatus and munication session may be terminated when a predeter- 
method that minimizes an initialization recovery procedure, mined number of errored messages (such as, for example, 
by retransmitting only the errored portion of a session three) occur. 

instead of completely restarting the initialization procedure. 5 Another object of the invention concerns a method for 
SUMMARY OF THE INVENTION minimizing a retransmission of signals and messages when 
Accordingly, an object of the present invention is to a ° e rrored message is received during a handshaking pro- 
develop a retransmission mechanism that retransmits an cedure of a communication session, by monitormg received 
errored message that occurs during handshaking or initial- data related to a predetermined frame structure of a high 
izing procedure. In a disclosed embodiment, the procedure 10 speed handshaking procedure (such as, for example, data 
is implemented as an extension to an xDSL handshaking and related to a Frame Check Sequence of an xDSL handshaking 
selection procedure (such as, but not limited to, for example, procedure), and transmitting a retransmission request mes- 
the above-noted ITU-T Recommendations G.994.1,V.8, and sage when the monitored predetermined frame structure 
V.8 bis). According to the instant invention, if a communi- indicates that the received data includes an errored message, 
cation device receives an errored message during a session, 15 In addition, the communication session can be terminated 
the communication device indicates the last correctly when a predetermined number of errored messages, such as, 
received message and requests a retransmission of the for example, three errored messages, are transmitted, 
errored message. In addition, an optional feature of the A stiU further object of the invention pertains to a method 
present invention enables the retransmission request mes- for minimizing a retransmission of signals and messages 
sages to surest the length of a message frame to be used by 20 when an errored m fa received durf an xDSL 
a communication device in order to help reduce the occur- j r ■ 
rence of frames with errois. negotiation procedure of a communication session. 
a 4 fi , . 4 . . . Received data related to a Frame Check Sequence is mom- 
According to an object of the invention, a communication _ , TP , u „ o L i o ■ ?■ * it _ . ^ 

device is disclosed that minimizes a retransmission of sig- t0red * Fr ?T Check Se ^ Uence indicates mat f he 

nals and messages when an errored message is received „ received data mcmdes an errored message, a retransmission 

during a communication handshaking procedure. The com- 25 re ^ uest m f sa & e I s tra ^ mi " ed ™* me *sage mcludes infor- 

munication device has a receiving section that receives matlon ldentlf y in g which correct message was lastly 

signals from an initiating communication device, in order to received. However, should a predetermined number of 

detect when an errored message is received, and a retrans- errored messages, such as three, occur, the communication 

mission request device that transmits, to the initiating com- session is terminated. In addition, the retransmission request 

munication device, a retransmission request message indi- 30 messa g e m Y contain information suggesting a frame length 

eating that the errored message was received. The receiving of subsequently transmitted signals. The suggested frame 

section includes an error detecting device that operates to len S lh mav be based u P on a frame len S lh of the correct 

detect errored messages. message that was lastly received. 

According to a feature of the invention, the retransmission 35 BRIEF DESCRIPTION OF THE DRAWINGS 

request message may indicate which correct message was Xhe foregoing other objects, features and advantages 

lastly received by the communication device. In addition, of the mvention wiU be t from the following m * re 

the retransmission request message can include information particular descr i ption 0 f preferred embodiments, as illus- 

related to for example, a suggested length of subsequent trated m me accompanying which are presente d as 

message frames to be transmitted, or a frame number of a 4Q a n0 n-limiting example, in which reference characters refer 

multi-segmented message. t0 ^ same parts throughout me varfous and wherein: 

According to another object of the current invention, a FIG. 1 illustrates a block diagram of a data communica- 

method is disclosed for minimizing a retransmission of tion tem usi a modem device accordin t0 an embodi . 

signals and messages when an errored message is received meQt of lhe Q{ mve nti 0 n; 

during a handshaking procedure of a communication ses- A * *n ♦ * a * i a ui i a- c j . 

a a * . .J? *i_ j *i_ i_ j i. i ■ j 45 FIG. 2 illustrates a detailed block diagram of a data 

sion. According to this method, the handshaking procedure • r t c ri „ - & 

• t a* a * u *J • • i • communication system of FIG. 1: 

is monitored to determine whether a received signal contains rj „ - .„ . 

an errored message. When the monitored handshake proce- , FIG " ?' U Ji S T trates an example lransactl0Q where a message 

dure determines that an errored message was received, a from a HSTU " R ao error i 

retransmission request message is transmitted to request , 0 FIG " 4 lllustrates ™ example transaction in which one 

retransmission of a portion of the handshaking procedure. frame of a multi-segment message contains an error. 

According to an advantage of the invention, data related FIG * 5 illustrates an example transaction where a message 

to a Frame Check Sequence is examined to determine from a HS ™-C contains an error; 

whether an errored message was received. FIG. 6 illustrates an example of a typical transaction in 

According to another advantage of the invention, the 55 which multi P le errors occur - 

retransmission request message may, for example, indicate a FIG - 7 illustrates an example transaction in which two 

last correctly received message, or, indicate a segment index errors occur in tne middle of the transaction; 

number of a multi-segment message, or, record the type (or FIG. 8 illustrates an example transaction in which three 

length) of the received message. In addition, a specific errors occur in the middle of the transaction; 

message type from a predetermined set of message types of 60 FIG. 9 illustrates an example transaction in which a 

the last correctly received message may be encoded with the HSTU-C that employs the present invention interacts with a 

retransmission request message. HSTU-R that does not employ the present invention; 

According to a feature of the invention, the retransmission FIG. 10 illustrates an example transaction in which an 

request message may indicate a suggested frame length of ACK message is not received error free; 

subsequently transmitted signals, which may be based, for 65 FIG. 11 illustrates an example transaction in which two 

example, on a frame length of a last correctly received errors occur in the middle of the transaction with an ACK as 

message. one of the errored messages; and 
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FIG. 12 illustrates an example transaction where an ACK 
for a multi-segmented message is received in error, 

DETAILED DESCRIPTION OF PREFERRED 

EMBODIMENTS 5 

A preferred embodiment of the present invention is 
described below in the context of a new message type, 
procedure, and associated transaction to an startup 
mechanism, such as, but not limited to, for example, an 
xDSL startup method defined in ITU-T Recommendation 10 
G.994.1. This new message type will be referred to herein- 
after as a "Request Retransmit" (RTX). 

The particulars shown herein are by way of example, and 
for purposes of illustrative discussion of embodiments of the 
present invention only, and are presented in the cause of 15 
providing what is believed to be the most useful and readily 
understood description of the principles and conceptual 
aspects of the present invention. In this regard, no attempt is 
made to show structural details of the present invention in 
more detail than is necessary for the fundamental under- 20 
standing of the present invention, the description taken with 
the drawings making apparent to those skilled in the art how 
the present invention may be embodied in practice. 

According to the current invention, if a communication 
device receives an errored message during a session (e.g., 25 
meaning a message containing at least 1 bit that is 
erroneous), the communication device requests a retrans- 
mission (RTX) of the errored message and indicates the last 
correctly received message to the communication device 
that transmitted the message. The RTX message may option- 30 
ally suggest the length of a message frame to be used by the 
communication device transmitting messages in order to 
help reduce the future occurrence of frames containing 
errors in the data transmission. 

While the present invention is presented herein with 35 
respect to ITU-T Recommendation G.994.1, it is noted that 
the functionality and methodology of using the RTX mes- 
sage and procedure is applicable to other handshake 
procedures, such as, but not limited to, the aforementioned 4Q 
ITU-T Recommendations V.8 and V.8 bis, without departing 
from the spirit and/or scope of the invention. 

FIG. 1 illustrates an example of an data communication 
system that implements the details of the handshake proce- 
dure of the present invention. As shown in FIG. 1, the data 45 
communication system comprises a central office system 2 
and a remote system 4, which are interfaced together via a 
communication channel 5. 

The central office system 2 includes a main distribution 
frame (MDF) 1 that functions to interface the central office 50 
system 2 to the communication channel 5. The main distri- 
bution frame (MDF) 1 operates to, connect, for example, 
telephone lines (e.g., communication channel 5) coming 
from the outside, on one side, and internal lines (e.g., 
internal central office lines) on the other side. 55 

The remote system 4 includes a network interface device 
(NID)3 that functions to interface the remote system 4 to the 
communication channel 5. The network interface device 
(NID) 3 interfaces the customer's equipment to the com- 
munications network (e.g., communication channel 5). 60 

It is understood that the present invention may be applied 
to other communications devices without departing from the 
spirit and/or scope of the invention. Further, while the 
present invention is described with reference to a telephone 
communication system employing twisted pair wires, it is 65 
understood that the invention is applicable to other trans- 
mission environments, such as, but not limited to, cable 
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communication systems (e.g., cable modems), optical com- 
munication systems, wireless systems, infrared communica- 
tion systems, etc., without departing from the spirit and/or 
scope of the invention. 

FIG. 2 illustrates a detailed block diagram of a first 
embodiment of the data communication system of FIG. 1. 
This embodiment represents a typical installation, in which 
both the central office system 2 and the remote system 4 
implement the instant invention. 

As shown in FIG. 2, the central office system 2 comprises 
a low pass filter 34 and a high pass filter 38, a test 
negotiation block 46, a high speed data receiving section 68, 
a high speed data transmitting section 70, and a computer 82. 
Computer 82 is understood to be a generic interface to 
network equipment located at the central office. Test nego- 
tiation block 46 performs all of the negotiation and exami- 
nation procedures which takes place prior to the initiation of 
an actual high speed data communication. 

The low pass filter 34 and high pass filter 38 function to 
filter communication signals transferred over the communi- 
cation channel 5. The test negotiation block 46 tests and 
negotiates conditions, capacities, etc. of the central office 
system 2, the remote system 4, and the communication 
channel 5. The procedures of the test negotiation block 46 
are completed prior to, and initiate the selection of the high 
speed modem receiving and transmitting sections (e.g., 
modems) 68 and 70. The high speed receiving section 68 
functions to receive high speed data transmitted from the 
remote system 4, while the high speed data transmitting 
section 70 transmits high speed data to the remote system 4. 
The high speed sections 68 and 70 may comprise, but not be 
limited to, for example, ADSL, HDSL, SHDSL, VDSL, 
CDSL modems. High speed sections 68 and 70 can be a 
plurality of high speed transmission devices which "share" 
the common block 46 during the initial negotiation proce- 
dure. The negotiation data receiving section 52 and the high 
speed data receiving section 68 transmit signals to computer 
82. The negotiation data transmitting section 54 and the high 
speed data transmitting section 70 receive signals issued 
from the computer 82. 

In the disclosed embodiment, test negotiation block 46 
comprises a negotiation data receiving section (e.g., a 
receiving section) 52 and a negotiation data transmitting 
section (e.g., retransmission request device) 54. The nego- 
tiation data receiving section 52 receives negotiation data, 
while the negotiation data transmitting section 54 transmits 
negotiation data. The operation of the various sections of the 
central office system 2 will be described, in detail, below. 

Remote system 4 comprises a low pass filter 36, a high 
pass filter 40, a test negotiation block 48, a high speed data 
receiving section 72, a high speed data transmitting section 
66, and a computer 84. Computer 84 is understood to be a 
generic interface to network equipment located at the remote 
system. Test negotiation block 48 performs all of the nego- 
tiation and examination procedures that take place prior to 
the actual high speed data communication. 

The low pass filter 36 and high pass filter 40 operate to 
filter communication signals transferred over the communi- 
cation channel 5. The test negotiation block 48 tests and 
negotiates conditions, capacities, etc. of the central office 
system 2, the remote system 4, and the communication 
channel 5. The high speed receiving section 72 functions to 
receive high speed data transmitted from the central office 
system 2, while the high speed data transmitting section 66 
transmits high speed data to the central office system 2. The 
negotiation data receiving section 56 and the high speed data 
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receiving section 72 transmit signals to the computer 84. The system 2, and the negotiation data receiving section 56 and 

negotiation data transmitting section 50 and the high speed negotiation data transmitting section 50 of the remote sys- 

data transmitting section 66 receive signals issued from the tem 4. 

computer 84. Th e essential features of the hardware portion of the 
In the disclosed embodiment, the test negotiation block 48 5 invention is the functionality contained in the test negotia- 
comprises a negotiation data receiving section 56 and a tion blocks 46 and 48, which test and negotiate the 
negotiation data transmitting section 50. The negotiation conditions, capabilities, etc. of the central office system 2, 
data receiving section 56 receives negotiation data, while the the remote system 4, and the communication channel 5. In 
negotiation data transmitting section 50 transmits negotia- practice, the configuration of the central office system 2 and 
tion data. The operation of the various sections of the remote 10 the remote system 4 is subject to wide variations. For 
system 4 will be described, in detail, below. example, the configuration of the external voice channel 33 
The negotiation data transmitting section 50 of the remote ^ not under the control of the same entities that control the 
system 4 transmits the upstream negotiation data to the central office system 2. Likewise, the capabilities and con- 
negotiation data receiving section 52 of the central system 2. figuration of the communication channel 5 are also subject 
The negotiating data transmitting section 54 of the central 15 t0 wide variation. In the disclosed embodiment, test nego- 
system 2 transmits the downstream negotiating data to the tiation blocks 46 and 48 are embedded within modems 42 
negotiation data receiving section 56 of the remote system 4. and 44. However, the functionality of test negotiation blocks 
The central office system 2 includes a plurality of chan- 46 and 48 ma y> alternatively, be implemented separate and 
nels 6, 10, 14, 16 and 18 that are used to communicate with distinct from the modems 42 and 44. Signals transmitted and 
a plurality of channels 22, 26, 28, 30 and 32 of the remote 20 received between the test negotiation blocks 46 and 48 are 
system 4. In this regard, it is noted that in the disclosed used for testin g tne environment itself as well as commu- 
embodiment, channel 6 comprises a central voice channel Seating the results of the tests between the central office 
that is used to directly communicate with a corresponding system 2 and the remote system 4. 

remote voice channel 32 in a conventional voice band (e.g., The purpose of each signal path in FIG. 2 will be 

0 Hz to approximately 4 kHz), which has been filtered by 25 explained below, followed by an explanation of the devices 

low pass filters 34 and 36. Further, a remote voice channel used to create the signals. Examples of specific values for 

33 is provided in the remote system 4 that is not under the the various frequencies will be discussed in detail, below, 

control of the central office system 2. Remote voice channel In the disclosed embodiment, frequency division multi- 

33 is connected in parallel with the communication channel 3Q plexing (FDM) is utilized for various communication paths 

5 (but prior to the low pass filter 36), and thus, provides the to exchange information between the central office system 2 

same service as the remote voice channel 32. However, since and the remote system 4. However, it is understood that 

this channel is connected prior to the low pass filter 36, the other techniques (such as, but not limited to, for example, 

remote voice channel 33 contains both the high speed data CDMA, TDMA, spread spectrum, etc.) may be used without 

signal and a voice signal. 35 departing from the spirit and/or scope of the present inven- 

It is noted that the filters may be arranged to have different tion. 

frequency characteristics, so that a communication may take The range from frequency 0 Hz until frequency 4 kHz is 

place using other, low band communication methods, such typically referred to as the PSTN voice band. Some of the 

as, for example, ISDN, between voice channels 6 and 32. newer communication methods typically attempt to use the 

The high pass filters 38 and 40 are selected to ensure a ^ frequency spectrum above 4 kHz for data communication, 

frequency spectrum above 4 kHz. It is noted that some Typically, the first frequency where transmission power is 

systems do not require, nor implement, some (or all) of the allowed occurs at approximately 25 kHz. However, any 

filters 34, 36, 38, and 40. frequency may be used. In this regard, it is noted that tone 

Bit streams 10, 14, 16 and 18 (in the central office system bursts at a frequency of 34.5 kHz are used to initiate T1E1 

2) and bit streams 22, 26, 28 and 30 (in the remote system 45 T1.413 ADSL modems. As a result, if possible, that fre- 

4) comprise digital bit streams that are used to communicate quency should be avoided in the spectrum used by precursor 

between the central computer 82 and the remote computer negotiation methods. 

84, respectively. It is understood that it is within the scope Communication paths are defined in pairs, one path for an 
of the present invention that bit streams 10, 14, 16, and 18 upstream communication from the remote system 4 to the 
could be implemented as discrete signals (as shown), or 50 central office system 2, and another path for a downstream 
bundled into an interface, or cable, or multiplexed into a communication from the central office system 2 to the 
single stream, without changing the scope and/or function of remote system 4. The negotiation upstream bits are trans- 
the instant invention. For example, bit streams 10, 14, 16 and mitted by the negotiation data transmitting section 50 of the 
18 may be configured as (but are not limited to) an interface remote system 4, and received by the negotiation data 
conforming to a RS-232, parallel, FireWire (IEEE- 1394), 55 receiving section 52 of the central office system 2. The 
Universal Serial Bus (USB), wireless, or infrared (IRDA) negotiation downstream bits are transmitted by the negotia- 
standard. Likewise, it is understood that bit streams 22, 26, tion data transmitting section 54 of the central office system 
28 and 30 can be implemented as discrete signals (as shown 2, and received by the negotiation data receiving section 56 
in the drawings), or bundled into an interface, or cable, or of the remote system 4. Once the negotiation and high speed 
multiplexed into a single stream, as described above. 60 training has been completed, the central office system 2 and 
Negotiation data (e.g., control information) correspond- the remote system 4 use high speed data transmitting see- 
ing to the condition of the communication line (e.g., fre- tions 66 and 70, and high speed data receiving sections 72 
quency characteristics, noise characteristics, presence or and 68 to perform a duplex communication, 
absence of a splitter, etc.), capabilities of the equipment, and All messages in the present invention are sent with one or 
user and application service requirements is exchanged 65 more carriers, using, for example, a Differential (Binary) 
between the negotiation data receiving section 52 and nego- Phase Shift Keying (DPSK) modulation. The transmit point 
tiation data transmitting section 54 of the central office is rotated 180 degrees from the previous point if the transmit 
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bit is a 1, and the transmit point is rotated 0 degrees from the 
previous point if the transmit bit is a 0. Each message is 
preceded by a point at an arbitrary carrier phase. The 
frequencies of the carriers, and the procedures for starting 
the modulation of carriers and messages, will be described 
below. 

The present invention goes to great lengths, both before 
the handshake procedure is performed and during the hand- 
shake procedure, to be spectrally polite or as non-obtrusive 
as possible. Carriers are typically selected so as to be 
different for the upstream and downstream paths, avoid 
existing system activation tones, be reasonably robust 
against inter-modulation products, have sufficient spacing, 
etc. Some suitable sets of carrier tones using 4.3125 kHz and 
4.0 kHz base frequencies, are shown in Table 1, below: 

TABLE 1 





Upstream 


Downstream 


Signal 


Frequency Indices 


Frequency Indices 


Designation 


(N) 


(N) 


A43 


9 17 25 


40 56 64 


B43 


37 45 53 


72 88 96 


C43 


7 9 


12 14 64 


A4 


3 


5 


B4 


4 28 34 


66 67 76 



10 



15 



20 



25 



30 



After the remote system 4 analyzes the equipment 
capabilities, the application desires, and the channel 
limitations, it makes a final decision on the communication 
method to use. 

After the central office system 2 has received the final 
decision, the transmission of the negotiation downstream 
data is stopped. When the remote system 4 detects the loss 
of energy (carrier) from the central office system 2, the 35 
remote system 4 stops transmitting the negotiation upstream 
data. After a short delay, the negotiated communication 
method begins it's initialization procedures. 
^When initiating a high speed communication session, one 
of the central office or remote systems transmits signals that 4Q 
are received by the opposite system, which responds by 
transmitting predetermined signals, such as, for example, 
signals required in a handshake session. These signals 
compromise one of a half duplex or full duplex start-up 
procedure. An example of such a start-up procedure is 45 
described in, for example, U.S. application Ser. No. 09/473, 
683, filed on Dec. 29, 1999, the disclosure of which is 
expressly incorporated by reference herein in its entirety. 
However, it is understood that alternative start-up proce- 
dures may be employed without departing from the spirit 50 
and/or scope of the current invention. The start-up procedure 
establishes a bi-directional communication channel for use 
by a handshake session.^ftther examples of handshake 
sessions include, but are"hTSt limited to, ITU-T Recommen- 
dationsV.8, V.8 bis, and G. 9 94.1 (formerly referred to as 55 
G.hs^/ 

AJfer the handshake session has been initiated, and before 
it is terminated, one or more transactions are used to 
exchange data between the xTU-C and the xTU-R. Each 
transaction comprises at least one message that contains data go 
and/or requests, and then concludes with an acknowledg- 
ment message (or a negative-acknowledgment message). 

The data includes, but is not limited to, for example: 
equipment capabilities, channel capabilities, available 
modes of operation, user requests, application requests, and 65 
service requests. Requests may include, but are not limited 
to, for example: a requested mode of operation, a requested 



data rate, and a requested protocol. The unit responding to 
a message indicates an acceptance (with an acknowledgment 
message), a rejection (with a negative-acknowledgment 
message), or a desire to initiate a different type of message 
with a request message. Depending on the response, a unit 
may initiate another transaction or terminate the handshake 
session. An acknowledgment to a mode selection message 
will cause the handshake session to be terminated, and the 
communication mode selected in the mode selection mes- 
sage to be initiated, using known techniques. 

In the discussion of the invention to follow, messages use 
the frame structure set forth in ITU-T Recommendation 
G. 994.1, noted above, as shown below in Table 2. It is noted 
that the two Frame Check Sequence (FCS) octets are used to 
determine if a message is received in error. However, it is 
understood that alternative frame structures can be 
employed without departing from the spirit and/or scope of 
the invention. 



TABLE 2 


Frame Structure 


Flag 


Octet 1 


Flag 


2 


Flag (optional) 




Flag (optional) 




Flag (optional) 




Information Field 




FCS (first octet) 


N-2 


FCS (second octet) 


N-l 


Flag 


N 


Flag (optional) 




Flag (optional) 





The overall composition of the Information Field (shown 
in Table 2) of the messages is shown in Table 3, below, 
including the RTX message of the present invention. 



TABLE 3 



Overall Message Composition 



Identification 



Non Standard 
Standard Information 





Message 






Information 


l+£<7 + M,) 
1=1 




Type & 




Service & 


Modulations 


Mes- 


Revision 


Vendor ID 


Channel 


& Protocols 


octets 


sages 


(2 octets) 


(8 octets) 


parameters 


available 


MR 


X 










CLR 


X 


X 


X 


X 


as necessary 


CL 


X 


X 


X 


X 


as necessary 


MS 


X 




X 


X 


as necessary 


ACK 


X 










NAK 


X 










REQ 


X 










RTX 


X 




X 







Table 4 lists typical message types defined in ITU-T 
Recommendation G. 994.1 and also adds support for the new 
RTX message of the present invention. Table 5 illustrates the 
manner in which a revision number is encoded. The revision 
number is examined to determine whether the RTX message 
type is supported. Specifically, if the revision number is set 
to 1 or below, the message extension (of the present 
invention) to ITU-T Recommendation G.994.1 is not 
supported, and thus, if an errored message is received, prior 
art error recovery techniques (e.g., transmission of a NAK- 
EF message followed a by session clear down and complete 
restarting) must be utilized. To utilize the RTX message and 
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its improved retransmission scheme of the current invention, 
the revision number must be greater than 1. 



TABLE 4 


Message tvne field format 
Bit Numbers 


Message type 


3 


7 


6 


5 


4 


3 


2 


1 


MS 


0 


0 


0 


0 


0 


0 


0 


0 


MR 


0 


0 


0 


0 


0 


0 


0 


1 


CL 


0 


0 


0 


0 


0 


0 


1 


0 


CLR 


0 


0 


0 


0 


0 


0 


1 


1 


ACK (1) 


0 


0 


0 


1 


0 


0 


0 


0 


ACK (2) 


0 


0 


0 


1 


0 


0 


0 


1 


NAK-EF 


0 


0 




0 


0 


0 


0 


0 


NAK-NR 


0 


0 




0 


0 


0 


0 


1 


NAK-NS 


0 


0 




0 


0 


0 


1 


0 


NAK-NU 


0 


0 




0 


0 


0 


1 


1 


REQ-MS 


0 


0 




1 


0 


1 


0 


0 


REQ-MR 


0 


0 




1 


0 


1 


0 


1 


REQ-CLR 


0 


0 




1 


0 


1 


1 


1 


RTX 


0 


1 


0 


0 


0 


0 


0 


0 


TABLE 5 




Revision Number field format 
















Bit numbers 








Revision number 


8 


7 


6 


5 


4 


3 


2 


1 


Revision 1 


0 


0 


0 


0 


0 


0 


0 


1 


Revision 2 


0 


0 


0 


0 


0 


0 


1 


0 


The RTX message has the format shown in Table 6, below. 
TABLE 6 


Octet Content 


RTX Frame Format 




Octet Index # 



10 



30 



Leading Flags 

Message type (RTX) 1 

Revision Number 2 

Last Correctly Received Message (LCRM) 3 

Multi-Segment Frame Number (MSFN) 4 

Suggested Frame Size (SFS) 5 

Frame Check Sequence (FCS) (2 octets) 6 

7 

Trailing Flags 



A description of each octet shown in Table 6, above, will 
now be described. 50 

The Message Type octet contains the unique number of 
the RTX message type as described in Table 4. 

The Revision Number octet indicates a version number of 
the transaction protocol that is being transmitted. This octet 
must be set greater than one (1) in order to indicate that this 55 
is a new message type. Table 5, above, illustrates encoding 
values. 

The Last Correctly Received Message (LCRM) octet 
contains the Message Type code of the last correctly 
received message. In the disclosed embodiment, a NULL 60 
message code (FF 16 ) is used for the LCRM octet when an 
error free message has not been received in the session. 
However, alternative message codes can be used without 
departing from the scope and/or spirit of the invention. 

The Multi-Segment Frame Number (MSFN) octet con- 65 
tains a segment index number of a message that has been 
segmented into a plurality of frames. A first segment (or a 
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message contained in one frame) has a MSFN value of 0. A 
second segment contained in the frame has a MSFN value of 
1, and so on. Although segment frames are not explicitly 
numbered, the HSTU-R and HSTU-C communication 
devices each maintain internal counters that implicitly keep 
track of the MSFN value. 

The Suggested Frame Size (SFS) octet contains a value 
suggesting to the other side (e.g. the remote system 4 when 
the RTX message containing the SFS octet is transmitted by 
the central office 2, or the central office system 2 when the 
RTX message containing the SFS octet is transmitted by the 
remote system 4) the length of subsequent message frames 
to be transmitted by the other side. Values for this octet are 
encoded as: 

FF 36 — Reserved for Future Use 

00 16 — No change of frame size suggested 

OOxx XXXX2— Size of frame 
It is understood that these values above are presented as an 
example implemented by the embodiment of the current 
invention. However, it is understood that such values are 
presented merely as an example, and changes to the values 
may be made without departing from the spirit and/or scope 
of the invention. 

In the disclosed embodiment, handshake transactions (to 
initiate a data communication) that include the RTX mes- 
sage must adhere to the following four minimum rules: 

(1) If a HSTU-x receives an errored message, the HSTU-x 
transmits (sends) an RTX message. The Last Correctly 
Received Message (LCRM) field contains the type of 
the last correctly received message. The Multi-Segment 
Frame Number (MSFN) octet and the Suggested Frame 
Size (SFS) octet are encoded in the manner described 
above. An example transaction is illustrated in FIG. 3, 
and will be described below; 

(2) If a HSTU-x receives an errored multi -segmented 
message, the Multi-Segment Frame Number (MSFN) field 
contains the message segment number. As previously 
described above, in the disclosed embodiment, the first 
segment has a MSFN value of 0. The second segment has a 
MSFN value of 1, and so on. Although the segment frames 
do not contain a field which explicitly numbers the frame, 
the HSTU-R (e.g., remote system 4) and the HSTU-C (e.g., 
central system 2) must maintain an implicit count of the 
number of frames that are received. An example transaction 
is illustrated in FIG. 4, and will be described below; 

(3) If a HSTU-x has not received an error free message 
during the handshaking session, the Last Correctly 
Received Message (LCRM) octet must contain the 
NULL message code. An example of such a session is 
illustrated in FIG. 5, and will be described below; and 

(4) If a HSTU-C receives an RTX message with the Last 
Correctly Received Message (LCRM) set to NULL, the 
HSTU-C must respond with a NAK-CD message to 
clear down (e.g., hangup/terminate) the session. An 
example of such a session is illustrated in FIG. 6, and 
will be described below. 

Two additional rules are contained in the disclosed pre- 
ferred embodiment. They are: 

(1) If a HSTU-x receives three successive RTX messages, 
the HSTU-x must send a NAK-CD message to clear 
down (e.g., hangup/terminate) the session; and 

(2) An RTX message is not "acknowledged". Thus, the 
transaction proceeds as if the errored message and the 
RTX message were not sent. 

With respect to the examples session shown in FIGS. 3 to 
12, it is noted that an arrow indicates a successfully received 
message, while an "X" indicates a received message that is 
errored. 
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It is noted that a HSTU-X does not have to retransmit 
exactly the same sequence of bits it transmitted in a message 
before receiving the RTX message. Since the errored mes- 
sage type cannot be positively known, the receiving 
HSTU-X should not make any assumptions about the con- 
tents of the errored frame. When the transmitting HSTU-X 
has been notified of an RTX, it can decide to shorten the 
message length in accordance with the Suggested Frame 
Size (SFS) octet. Additionally, the transmitting HSTU-X 
may decide to change the contents (or the message type), 
knowing that the communication channel is likely to have 
future errors. 

The above discussion was presented with an embodiment 
in which the first message is always sent by the HSTU-R. 
However, the instant invention is equally applicable in the 
situation in which the first message is transmitted by the 
HSTU-C. Accordingly, it is understood that the first message 
can be transmitted by the HSTU-C without departing from 
the spirit and/or scope of the invention. 

An explanation of the use of the invention will now be 
presented with reference to FIGS. 3 to 12. In this regard, it 
is understood that the following examples are provided 
merely for illustrative discussion, and are not to limit the 
scope of the invention. 

In the example illustrated in FIG. 3, the HSTU-C suc- 
cessfully receives a CLR message transmitted by the HSTU- 
R. The HSTU-R then receives a CL message from the 
HSTU-C. Thereafter, the HSTU-R sends an ACK message 
and then, a MS message to the HSTU-R. Although the 
HSTU-R sent the MS message to the HSTU-C, the HSTU-C 
does not receive the message error free. Since the last 
correctly received message from the HSTU-R was an ACK 
message, the HSTU-C prepares an RTX message with the 
LCRM field set to the code of the ACK message. When the 
HSTU-R receives the RTX message, it determines that the 
ACK message was correctly received but that the data 
thereafter (e.g., the MS message) was not correctly received. 
As a result, the HSTU-R retransmits the MS message. 
Although not shown in the FIG. 3, the transaction then 
continues using standard transaction rules. 

FIG. 4 illustrates the sending of a multi-segment CLR 
message by the HSTU-R, with each segment being acknowl- 
edged by an ACK(2) message. A first segment is implicitly 
numbered 0, a second segment is implicitly numbered 1, and 
so on. A third segment of the CLR message transmitted by 
the HSTU-R is not received by the HSTU-C free of any 
errors. Accordingly, the HSTU-C prepares an RTX message 
with the LCRM set to CLR. Since the CLR message is a 
multi-segment message, the MSFN field is encoded with 1 
(e.g., CLR a ) to indicate that the second segment of the 
multi-segment message was the last segment correctly 
received. When the HSTU-R receives the RTX message, it 
determines that the second segment (e.g., CLR a ) was 
received error free but the third segment (e.g., CLR 2 ) was 
not received. Thus, the HSTU-R retransmits the third seg- 
ment (e.g., CLR 2 ) of the CLR multi-segmented message. 
Although not shown in FIG. 4, the transaction then contin- 
ues using standard transaction rules. 

FIG. 5 illustrates the example in which the HSTU-R does 
not receive the first message sent by the HSTU-C. The 
transaction begins with the HSTU-C successfully receiving 
the CLR message transmitted by the HSTU-R. Then, the 
HSTU-C transmits a CL message to the HSTU-R. However, 
the CL message is not received by the HSTU-R free of 
errors. Since there is no last correctly received message from 
the HSTU-C, the HSTU-R prepares a RTX message with the 
LCRM field set to the code of NULL. When the HSTU-C 
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receives the RTX message, it determines that no message 
was correctly received. Thus, the HSTU-C retransmits the 
first message (e.g., the CL message). Although not shown in 
FIG. 5, the transaction then continues using standard trans- 

5 action rules. 

In the example illustrated in FIG. 6, the communication 
channel initially is not error free. The HSTU-R transmits a 
CLR message to the HSTU-C, but it is not received error 
free by the HSTU-C. The HSTU-C informs the HSTU-R of 

10 this error by transmitting a RTX message with the LCRM set 
to NULL. However, due to, for example, problems with the 
communication channel, this message also is not error free. 
As a result, the RTX message is not correctly received by the 
HSTU-R. Thus, the HSTU-R prepares its own RTX message 

15 with the LCRM set to NULL, which indicates that the 
HSTU-R has not received any error free messages from the 
HSTU-C. In this example, the channel conditions have now 
improved, and the RTX message is received by the HSTU-C 
error free. Since the RTX message has a LCRM message of 

20 NULL, the HSTU-C determines that its RTX message (e.g., 
the first RTX(NULL) shown in FIG. 6), indicating that it had 
not received an error free message from the HTSU-R, was 
also not received error free. Accordingly, the HSTU-C 
terminates the session by sending a NAK-CD message to the 

25 HSTU-R. 

FIG. 7 illustrates an example in which the quality of a 
communication channel deteriorates (resulting in the recep- 
tion of two errored messages) during a transaction, and then, 
the quality of the communication channel improves, so as to 

30 allow a subsequent error free message reception during the 
handshaking session. The HSTU-C successfully receives the 
CLR message that was transmitted by the HSTU-R. 
Although the HSTU-C sends an CL message to the HSTU- 
R, the HSTU-R does not receive the message error free. 

35 Since there is no last correctly received message from the 
HSTU-C, the HSTU-R prepares an RTX message in which 
the LCRM field is set to NULL. Since the channel degra- 
dation problem continues, the HSTU-C again fails to receive 
an error free message. Thus, the HSTU-C prepares and 

40 transmits a RTX message with the LCRM field set to CLR. 
Since the quality of the communication channel has 
improved at this point, the HSTU-R receives the RTX 
message, determines that its RTX (NULL) message was not 
received error free, and retransmits the RTX message with 

45 the LCRM field set to NULL. The HSTU-C receives the 
RTX message, determines that its CL message was not 
received error free, and retransmits the CL message. 
Although not shown in FIG. 7, the transaction then contin- 
ues using the standard transaction rules. 

50 FIG. 8 illustrates an example transaction in which the 
quality of a communication channel deteriorates (resulting 
in the reception of three errored messages) during the 
transaction, and then, the quality of the communication 
channel improves, so as to allow a subsequent error free 

55 message reception during the handshaking session. The 
HSTU-C successfully receives the CLR message that was 
transmitted by the HSTU-R. Although the HSTU-C sends an 
CL message to the HSTU-R, the HSTU-R does not receive 
the message error free. Since there is no last correctly 

60 received message from the HSTU-C, the HSTU-R prepares 
an RTX message in which the LCRM field is set to NULL, 
however, because the channel degradation problem 
continues, the HSTU-C again fails to receive an error free 
message. Thus, the HSTU-C prepares and transmits a RTX 

65 message with the LCRM field set to CLR. Since the channel 
degradation problem continues, the HSTU-R again fails to 
receive an error free message. Again, the HSTU-R prepares 
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an RTX message in which the LCRM field is set to NULL, message is an acknowledgment to a multi-segment message, 

since it has never received an error free message from the the MSFN field is encoded with 0 (e.g., ACK(2) 0 ) to indicate 

HSTU-C. At this point, the quality of the communication that the first ACK(2) of the multi-segment message was the 

channel has improved, and the HSTU-C receives the RTX last segment correctly received. When the HSTU-C receives 

message transmitted from the HSTU-R, determines that its 5 the RTX message, it determines that the first segment (e.g., 

first CL message was not received error free, and retransmits ACK(2) 0 ) was received error free but the second ACK(2) 

the CL message. Although not shown in FIG. 8, the trans- ( e *g> ACK(2)j) was not received. Thus, the HSTU-C 

action then continues using standard transaction rules. retransmits the second ACK(2) (e.g., ACK(2) 1 ). The 

FIG. 9 illustrates an example transaction of a HSTU-C HSTU-R then continues the transaction by transmitting the 

utilizing the present invention that interacts with a HSTU-R 10 third segment of the CLR message (e.g. CLRj). Although 

that does utilize the present invention. The HSTU-C sue- not shown in FIG. 12, the transaction then continues using 

cessfully receives the CLR message that was transmitted by standard transaction rules. 

the HSTU-R. At this point, the quality of the communication The foregoing discussion has been provided merely for 

channel deteriorates, and a CL message sent by the HSTU-C the purpose of explanation and is in no way to be construed 

to the HSTU-R is not received error free by the HSTU-R. a 5 as limiting of the present invention. While the present 

Since the HSTU-R does not employ (utilize) the present invention has been described with reference to exemplary 

invention, prior art techniques are employed. Specifically, embodiments, it is understood that the words which have 

the HSTU-R prepares and transmits a NAK-EF (errored been used herein are words of description and illustration, 

frame) message followed by a termination of the commu- rather than words of limitation. Changes may be made, 

nication session. Since the channel degradation problem 20 within the purview of the appended claims, as presently 

continues, the HSTU-C again fails to receive an error free stated and as amended, without departing from the scope and 

message. The HSTU-C (which, as noted above, utilizes the spirit of the present invention in its aspects. Although the 

present invention) prepares and transmits a RTX message present invention has been described herein with reference 

with the LCRM field set to CLR. When the HSTU-C fails to to particular means, materials and embodiments, the present 

receive a response from the HSTU-R, the HSTU-C termi- 25 invention is not intended to be limited to the particulars 

nates after a timeout period lapses. disclosed herein; rather, the present invention extends to all 

FIG. 10 illustrates an example transaction in which an functionally equivalent structures, methods and uses, such as 

ACK message is received with errors. The HSTU-C sue- are within the scope of the appended claims. For example, 

cessfully receives an MS message that was transmitted by while the present invention has been described with respect 

the HSTU-R. However, although the HSTU-C sends an 30 to the xDSL procedure defined in ITU-T Recommendation 

ACK message to the HSTU-R, the HSTU-R does not receive G.994.1, the present invention is not limited to being used 

the message error free. Since there is no last correctly with this procedure, but is equally applicable with other 

received message from the HSTU-C, the HSTU-R responds procedures, such as, for example, ITU-T Recommendations 

by preparing an RTX message, in which the LCRM field is V.8 and V.8 bis. The methods described herein comprise 

set to NULL. Since the HSTU-C determines that no message 35 dedicated hardware implementations including, but not lim- 

has been correctly received, the HSTU-C retransmits the ited to, application specific integrated circuits, program- 

ACK message, completing the transaction. mable logic arrays and other hardware devices constructed 

FIG. 11 illustrates an example transaction in which two to implement the methods described herein. However, it is 
errors occur in the middle of the transaction, with an ACK understood that the invention may be implemented in soft- 
being one of the errored messages. The HSTU-C success- 40 ware (e.g., a software modem) that is executed by a com- 
fully receives the MS message that was transmitted by the puter. Furthermore, alternative software implementations 
HSTU-R. The HSTU-C then sends an ACK message to the including, but not limited to, distributed processing or 
HSTU-R, however, due to a deterioration in the quality of component/object distributed processing, parallel 
the communication channel, the HSTU-R does not receive processing, or virtual machine processing can also be con- 
the message error free. Since there is no last correctly 45 structed to implement the methods described herein. In 
received message from the HSTU-C, the HSTU-R prepares addition, although the present specification describes com- 
an RTX message in which the LCRM field is set to NULL. ponents and functions implemented in the embodiments 
Since the channel degradation problem continues, the with reference to particular standards and protocols, the 
HSTU-C again fails to receive an error free message. Thus, invention is not limited to such standards and protocols. The 
the HSTU-C prepares and transmits a RTX message with the 50 standards for Internet and other packet-switched network 
LCRM field set to MS. Since the quality of the communi- transmission (e.g., TCP/IP, UDP/IP, HTML, SHTML, 
cation channel has improved at this point, the HSTU-R DHTML, XML, PPP, FTP, SMTP, MIME); peripheral con- 
receives the RTX message, determines that its RTX(NULL) trol (IrDA; RS232C; USB; ISA; ExCA; PCMCIA); and 
message was not received error free, and retransmits the public telephone networks (ISDN, ATM, xDSL) represent 
RTX message with the LCRM field set to NULL. The 55 examples of the state of the art. Such standards are periodi- 
HSTU-C receives the RTX message, determines that its cally superseded by faster or more efficient equivalents 
ACK message was not received error free, and retransmits having essentially the same functions. Replacement stan- 
the ACK message. The transaction is then complete. dards and protocols having the same functions are consid- 

FIG. 12 illustrates an example transaction where an ACK ered equivalents. 

(2) for a multi-segmented message is received in error. A 60 I claim: 

multi-segment CLR message is transmitted by the HSTU-R, 1. A communication device that minimizes a retransmis- 

with each segment to be acknowledged by an ACK(2) sion of signals and messages when an errored message is 

message. A first segment is implicitly numbered 0, a second received during a communication handshaking procedure 

segment is implicitly numbered 1, and so on. A second performed in a negotiation operation to identify a commonly 

ACK(2) sent by the HSTU-C is not received error free by the 65 supported communication standard, comprising: 

HSTU-R. Accordingly, the HSTU-R prepares an RTX mes- a receiving section that receives signals from an initiating 

sage with the LCRM set to ACK(2). Since the ACK(2) communication device, said receiving section detecting 
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when an errored message is received during the com- 
munication handshaking procedure; and 
a retransmission request device that transmits, to the 
initiating communication device, a retransmission 
request message indicating that said errored message 
was received. 

2. The communication device of claim 1, wherein said 
retransmission request message indicates which correct 
message was lastly received by the communication device, 
a retransmission commencing with a message after the last 
correctly received message. 

3. The apparatus of claim 2, wherein said retransmission 
request message further comprises information related to a 
suggested length of subsequent message frames to be trans- 
mitted to the communication device. 

4. The apparatus of claim 2, wherein said retransmission 
request message further comprises information related to a 
frame number of a multi-segmented message. 

5. The apparatus of claim 1, wherein said receiving 
section further comprises an error detecting device that 
detects said errored message. 

6. A method for minimizing a retransmission of signals 
and messages when an errored message is received during a 
handshaking procedure of a communication session that 
identifies a commonly supported communication standard, 
comprising: 

monitoring the handshaking procedure that identifies a 
commonly supported communication standard to deter- 
mine whether a received signal contains an errored 
message; and 

transmitting a retransmission request message requesting 
retransmission of a portion of the handshaking proce- 
dure when the monitored handshake procedure is deter- 
mined to contain the errored message. 

7. The method of claim 6, wherein monitoring the hand- 
shaking procedure comprises determining the errored mes- 
sage has been received by examining data related to a Frame 
Check Sequence. 

8. The method of claim 7, further comprising encoding a 
specific message type from a predetermined set of message 
types of the last correctly received message. 

9. The method of claim 6, wherein transmitting a retrans- 
mission request message further comprises indicating a last 
correctly received message, a retransmission commencing 
with a message after the last correctly received message. 

10. The method of claim 6, wherein the retransmission 
request message further comprises encoding a segment 
index number of a multi-segment message. 

11. The method of claim 6, wherein the retransmission 
request message further comprises indicating a suggested 
frame length of subsequently transmitted signals. 

12. The method of claim 11, wherein the suggested frame 
length of subsequently transmitted signals is based on a 
frame length of a last correctly received message. 

13. The method of claim 6, wherein monitoring the 
handshaking procedure comprises examining data related to 
a Frame Check Sequence. 

14. The method of claim 13, further comprising recording 
what type of message was received. 

15. The method of claim 13, further comprising recording 
a length of the received message. 

16. The method of claim 6, further comprising terminat- 
ing the communication session when a predetermined num- 
ber of errored messages occur. 
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17. The method of claim 16, wherein the predetermined 
number is three. 

18. A method for minimizing a retransmission of signals 
and messages when an errored message is received during a 
handshaking procedure of a communication session, com- 
prising: 

monitoring received data related to a predetermined frame 
structure of a high speed handshaking procedure that 
identifies a commonly supported communication stan- 
dard; and 

transmitting a retransmission request message when the 
monitored predetermined frame structure indicates that 
the received data of the high speed handshaking pro- 
cedure includes an errored message. 

19. The method of claim 18, wherein monitoring received 
data related to a predetermined frame structure comprises 
monitoring received data related to a Frame Check Sequence 
of an xDSL handshaking procedure. 

20. The method of claim 19, wherein transmitting a 
retransmission request message further comprises indicating 
which correct message was lastly received, a retransmission 
commencing with a message after the last correctly received 
message. 

21. The method of claim 20, further comprising termi- 
nating the communication session when a predetermined 
number of errored messages are transmitted. 

22. The method of claim 21, wherein the predetermined 
number is three. 

23. The method of claim 18, wherein transmitting a 
retransmission request message further comprises indicating 
which correct message was lastly received, a retransmission 
commencing with a message after the last correctly received 
message. 

24. The method of claim 18, further comprising termi- 
nating the communication session when a predetermined 
number of errored messages are transmitted. 

25. The method of claim 24, wherein the predetermined 
number is three. 

26. A method for minimizing a retransmission of signals 
and messages when an errored message is received during 
an xDSL negotiation procedure to identify a commonly 
supported communication standard for establishing a com- 
munication session, comprising: 

monitoring received data related to a Frame Check 
Sequence during the xDSL negotiation procedure; 

transmitting a retransmission request message when the 
Frame Check Sequence indicates that the received data 
includes an errored message, the retransmission request 
message indicating which correct message was lastly 
received; and 

terminating the communication session if a predetermined 
number of errored messages occur. 

27. The method of claim 26, wherein the predetermined 
number is three. 

28. The method of claim 26, wherein transmitting a 
retransmission request message further comprises suggest- 
ing a frame length of subsequently transmitted signals. 

29. The method of claim 28, wherein the suggested frame 
length is based upon a frame length of the correct message 
that was lastly received. 

30. The method of claim 29, wherein terminating the 
communication session comprises terminating the commu- 
nication session if three errored messages occur. 
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